home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10288 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: inforamp.net!ts9-03
  2. From: rmorin@inforamp.net (Randy Charles Morin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: Thu, 07 Mar 96 05:16:03 GMT
  6. Organization: MiddleWorld SoftWare
  7. Message-ID: <4hlreg$6jg@sam.inforamp.net>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hjh5c$elk@flood.weeg.uiowa.edu>
  9. NNTP-Posting-Host: ts9-03.tor.inforamp.net
  10. X-Newsreader: News Xpress Version 1.0 Beta #4
  11.  
  12. In article <4hjh5c$elk@flood.weeg.uiowa.edu>,
  13.    maclenna@ozone.uiowa.edu (Mark MacLennan) wrote:
  14. >Some of their coding standards requirements you list are actually
  15. >quite good, some are more dubious.  Most coding standards are intended
  16. >as guidelines to be followed unless common sense dicticates otherwise
  17. >(and these deviations are documented accordingly).  You should probably
  18. >discuss this with the company, inquire as to the intent of some of
  19. >the standards, rather than laugh behind their back.
  20. >Some of the items you list reveal your own unfamiliarity with C++,
  21. >which is perhaps one reason they have defined a set of C++ coding
  22. >standards. (Hopefully the company isn't paying you based on spelling ...)
  23.  
  24. I ran a spell check on our documents and found four spelling mistakes.  They 
  25. were all yours.  The words are dicticates, explicitedly, curiousity and 
  26. inplemented.  I couldn't find one spelling mistake in my document.  Obviously 
  27. your only purpose was to criticize.  I went through your comments and found 
  28. that your lack of knowledge of C++ is even worse then your spelling.
  29.  
  30. >>    -never use #define instead or const.  What if your concerned about the 
  31. >>mix between code space and data space.
  32. >Not bad advice.  Pre-processor directives should be avoided if possible.
  33. >Better error checking too.
  34.  
  35. One statement puts the data in the code section and the other puts it in the 
  36. data section.  I guess the people who made the coding standard didn't know 
  37. that.  I guess you didn't either.  This is not important when you compile a 
  38. "Hello World" example from a textbook, but it makes a difference in the 64k 
  39. DOS world.
  40.  
  41. >>    -don't use conditional compilation preprocessor directives.  There 
  42. >>goes cross-platform development.
  43. >Huh?  Since these are pre-processor commands, simply run your code 
  44. >through the pre-processor for the particular platform your client wants
  45. >the software for.  What's the big deal from your point-of-view?  Out-of-
  46. >curiousity, I would inquire as to why they have this programming standard.
  47.  
  48. Read the above.  It says no conditional compilation preprocessor directives.  
  49. Yet you are still using them.  And do you think the contractee is going to 
  50. accept preprocessed code?  Maintenance would be very expensive.
  51.  
  52. >>    -optimize code only when you have a problem.  So we can't optimize 
  53. >>size in order to anticipate that code size will be a problem.  First we have 
  54. >>to experience the problem (most likely in the field).
  55. >Perhaps they want well-written code that they and other
  56. >future programmers can read rather than tricky "optimized" code.
  57. >The code can always be tweaked for specific hardware at a later
  58. >time.  There is no reason that you can't write efficient code using
  59. >appropriate algorithms and data structures.
  60.  
  61. Read the above.  It says no optimizations until you have a problem.  Yet you 
  62. are still optimizing before any problems.
  63.  
  64. >>    -access functions are to be inline.  Inline access functions defeat 
  65. >>the purpose of having access functions.
  66. >This isn't clear.  Having access functions inplemented inline isn't
  67. >such a bad idea.
  68.  
  69. If an access function's data member's type changes, then what?  You have to 
  70. recompile and redistribute every module that uses the access function.  
  71. Several thousand customers might use that accessor.  Sort of defeats the 
  72. purpose of hiding data members.  
  73.  
  74. From your e-mail address and your posts, I'm assuming that you are a student 
  75. at U of Iowa.  Tell me if I'm wrong.  Please, before you respond, note that I 
  76. saw your response as pompous and slow-witted.  I have tried to responded to 
  77. your pompous and slow-witted post very tactfully.  Please, don't make the same 
  78. mistake twice.
  79.  
  80. Agrivar
  81.